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ABSTRACT 



Traditionally, it has been difficult to share data among 
diverse computer applications and platforms because of 
underlying differences in data formats. Although the mean- 
ing or purpose of the data may be similar or identical (for 
example, two appointments entered using separate computer 
applications), the differences in data formats required by the 
various computer applicatioos and platforms renders such 
sharing difficult A method is disclosed for the translation of 
dissimilarly-formatted data between disparate computer 
applications and platforms. The method also provides for the 
dynamic reconciliation of conflicts in the data (for example, 
two appointments scheduled at the same time) based on both 
the content of the data and on spedflc preferences indicated 
by the user of the translation facility. First, the data is 
translated to a common format based on the user-specified 
mapping of data fields (identifying handheld and desktop 
fields to be translated) and considering the characteristics of 
the handheld or desktop computer ^plication. Then, if the 
specific data item (such as an appointment, telephone book 
entry, or memo entry) akcady exists on the desktop com- 
puter application or platform, the user is c^tionally notified 
of the conflict and given the opportunity to replace the 
existing data, ignore the incoming data, or modify flie 
incoming data. The criteria for determining the existence of 
conflicts is disclosed for updating schedule information and 
keyed databases. 

9 Qafans, 8 Drawing Sheets 

Microfiche Appendix Included 
(1 Miaofiche, 330 Pages) 
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METHOD FOR MAPPING, TRANSLATING, described by the fields* names, data fannats, and byte offsets 

AND DYNAMICALLY RECONCILING DATA in the record. The file fonnafs rules include a descriptioD of 

BETWEEN DISPARATE COMPUTER record structure of the constituent data records, the 

PLATFORMS record structure for any header records and how these header 

5 records aid navigation to find specific data records and/or 

This is a continuation of application Ser. No. 07/8^7,167, specffic fields within those records, "hidden" key togs to 

filed Apr. 10. 1992, now U.S. Pat No. 5392,390. ^ V'^^y that apphcation programs 

*^ use to access a particular record and field. 

REFERENCE TO MICROHCHE APPENDIX Database files are managed by two tooad classes of 

jQ programs, database managers and other application pro- 

A source code listing of the preferred embodiment of the grams. A database manager is a program for managing 

invention is appended in the form of a fiche and 330 pages general databases, that is, database files whose record struc- 

rccorded on microfiche. turc can be specified at creatioD time by the user. Database 

A portion of the disclosure of this patent document manager ^ograms rnaintom 

contains material thatissubjecttocopyrightprotection. The 15 the <btobasc file. ITies^ 

copyright owner has no objection to ttteflcsLler^^^ each field s n^e, start byte offset withm the record, and 

tion by^nyone of the patent document or the patent dxsdo ^^^^^ ^^S^ ^'""^^ 

sure as it appears in the Patent and IVademark Office file or "^^"^^^ P^^^^^' Cuir^^^ 

records, but otherwise reserves all copyright rights whatso- Other database files are managed by speaal-pmpose 

gygP application programs. These programs work on databases of 

one specified record structure; this specification is embedded 

BACKGROUND OF THE INVENTION ^ ^® program rather than in header records of 

the file. For instance, a telephone directory program may 

This invention relates to programs that share data across work on files with a 32-character name and a 10-oharacter 

disparate cconputer ^yplications and platforms, such as phone number. This record structure would have been 

handheld computers and desktop con^uters. ^ encoded in a data structure declaration in the source of the 

Handheld con^uters typically weigh less than a pound program, 

and fit in a pocket Handheld computers typically provide One or more of the fields of a database record structure are 

some combination of personal information management designated as the key, the "name** by which the record can 

functions, database functions, word processing functions, be spcdfied for reading or writing. Some database files, 

and spreadsheet functions. Owing to the physical and typically those for schedule application programs, have 

memory size, and processing power limitations of the hand- 'Yange keys" — the key specifies start and end points in a 

held coitqjuters, however, these applications are generally 1-dimensional key space rather than a single point in the 

limited in functionality and differ in data content and usage (possibly multi-dimensional) key space. Range keys may 

from similar applications on desktop computers. specify multiple intervals, for instance **9 AM to 10 AM 

Many users of handheld con^uters also own a desktop every Monday until November 17." Where non-range keys 

computer used for applications that manage data similar to must be unique — there cannot be two records with the same 

the data carried in the handheld coii5)utcr. In such cases, the non-range key— range keys may overlap or even be exactiy 

user normally would want the same data on the desktop equal, though typically these are undesirable situations and 

computer as in the handheld computer. There are a number ^ should brought to the attention of the user, 

of programs tiiat transfer data between handheld computers Because handheld computers of the current generation are 

and desktop conq)uters, but they all aeate desktop consul- diskless, '"files** in tiie classical sense do not exist on many 

er's data with no regard for prior contents. As a result, all of these handheld computers. Within this patent, the term file 

updates that have been done to the desktop compute's data should be understood to include the memory-resident 

prior to the transfer are ignored. 45 datasets of a handheld con^uter, and the serial bit stream 

Many desktop computer applications have Iheir data format in whidi a handheld computer sends or receives data 

stored in large, con^lex, proprietary fannats. Data transfer to/from another computer. 

to these appUcadons usually cannot take place through file File copying and data conversion are long-standing prob- 

transfer, because the data comes fi-om the handheld com- lems in the art, and many solutions to different parts of the 

putcr in a diffaent format and usually is a subset of the data 50 problem have been offered, 

held on the desktop computer. In sudi cases, data can only U3. Pat. No. 4,966,809 describes a technique fos^ sharing 

be conmmnicated to and from the desktop application by the data among disparate platforms with differing data formats, 

use of a database manager or by use of dynamic inter* but leaves unsolved the problems of sharing data among 

application conmmnication techniques. platforms that require different record structures or file 

Many handheld and desktop parograms work with database 55 formats (broader problems that include the data format 

files. Database files have a file format, the set of rules by problem as a constituent), and docs not provide a method for 

which data can be read from or written to the file. A database a user of these disparate platforms to conveniently instruct 

file is composed of records, some of which are data records his system about his environment so that the system will 

with the data of interest to the application program and the ^pply itseff in that enviromnent. 

user, and often some header records. Eadi data record is 60 There are several file transfer programs for communicate 

con4>osed of fields, and eadi field has a name and a data ing between computes, including Organizer Link 2 from 

format Exan^les of data formats include 1-, 2-, and 4-byte Sharp® Electronics, PC-Link for the Casio B.O.S .S from 

integers, a 4-bytc or 8-byte floating point number, or one or Traveling Software®, HP95LX Connectivity Pack from 

more ASCH text strings. In the case of multiple text strings Hewlett Packard, and 3 Link from Psion PLC. These file 

in one field, the strings (or subfields) are separated by a 65 transfer programs do not provide the invention* s user- 
special character such as tab or linefeed. Each data record of specifiable field mailing of data nor dynamic reconciliation 

a file shares the same record structure: a record structure is of data. 
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SUMMARY OF THE INVENTION 

The cuxrent invendon solves the problem of sharing data 
between disparate application programs by providing user- 
specifiable field mapping of data and dynamic reconciliation 
of conflicts. 

In preferred embodiments, the invention features accept- 
ing data from a first con^}uta application, and then mapping 
and translatiiig the data to the formats expected by a second 
computer application. The user of the translation facility 
may explicitly specify the mapping of the data fields of the 
two applications* files. During ttie data transf er« the user may 
also choose to be informed of application-specific conflicts 
between data received from the first application and that 
already existing on tiie second platform. When a data 
conflict is encountered, the user may then opt to accept, 
ignore, or change the data before it is applied to the second 
application's files. 

The invention can also be used to transfer, compare and 
reconcile data between any other pair of disparate platforms, 
even if the disparity is relatively minor, as for instance 
between a Paradox database manager and a dBase database 
manager running on the same IBM PC. 

The invention provides an effective method of translating 
data between disparate computer platforms and a wide 
variety of applications, while ensuring that the data need 
only be entered once (and not duplicated). 

The invention also ensures the integrity of the data 
iiiq)orted to conaputer implications, through the process of 
conflict resolution (also known as data recondliation). 

In a first aspect, the invention features a method for an 
interactive user of a computer to dynamically reconcile the 
information of two database files. The method con^rises the 
steps of choosing concsponding records &om the two files, 
comparing the information of corresponding fields of these 
records, and allowing the user to decide how to change the 
data in one of the two files to bring them into agreement 

In preferred embodiments in which the records of the two 
files are named by range keys, as in an appointment schedule 
application, the method comprises determining if any sched- 
ifle conflicts exist (either the time of an appointment has 
been changed in one of the two schedule databases, or there 
are two different appointments for conflicting times) and 
allowing the user to decide how to change the data in one of 
the two files to bring them into agreement 

The invention offers a solution to previously unsolved 
portions of the data translation problem, by providing means 
to translate data from one record structure to another. 

In a second aspect, the invention features a method for 
transladng computer data from a source record structure to 
a destination record structure. Ihe invention offers transla- 
tions that are new in the art, by translating between source 
and destination record structures that differ in field naming, 
field order, or one-to-many or many-to-one field correspon- 
dence. The method comprises the steps of establishing a 
mapping between the fields of the two record structures, and 
using that mapping to translate the data of a source file into 
the destination record structure. 

The invention provides both a framework and a conve- 
nient user interface for tying together previous data trans- 
lation techniques into a more broadly-applicable and easy- 
to-use system. 

In a third aspect, the invention features a method for 
translating computer data from a source record structure to 
a different destination record structure. The method comr 
prises the steps of first establishing a mapping between the 
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fields of tiie two record structures by presenting the names 
of the fields of each of the record structures on a display, and 
allowing a user to specify the correspondence between pairs 
of fields. The actual translation of files then naakes use of this 
5 mapping to translate the data of a file from the source record 
structure to the destination record structure. 

Other features and advantages of the invention will be 
apparent from the following description of preferred 
embodiments, and from the claims. 

10 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of a prefctred embodiment of 
the mvention. 

FIG. 2 shows exa^^>Ies of the transfer and translation of 
data &om handheld applications and computers to common 
record structures. 

FIG. 3 shows exan^les of tiic transfer and translation of 
data from the common record structures to desktop apjdi- 
20 cations and conqsuters. 

FIG. 4 shows an example of the detailed mapping of fields 
(specifying correspondence between handheld and desktop) 
between a handheld and desktop applications. 

FIGS. 5A and 5B show a sample saeen display ^^luch 
^ enables the user to specify the mapping or correspondence 
of field names between handheld and desktop q)plications 
and platforms. 

FIG. 6 shows an application-specific reconciliation table 
used internally by the translation software to achieve data 
^ reconciliation. 

FIG. 7 shows a sample screen display which notifies the 
user of conflicts between handheld and desktop data for 
reconciliation purposes. 
35 FIG. 8 shows a sample screen display which notifies the 
user of conflicts between schedule data contained on the 
handheld and desktop applications and platforms. 

FIG. 9 shows the field structure of tiie field moping 
database. 

40 FIG. 10 shows a saiiq)le field mapping database. 

FIG. 11 shows an example of data translated between a 
handheld computer database and a desktop con^uter data- 
base. 

45 DESCRIPTION OF THE PREFERRED 

EMBODIMENT(S) 

The prefccred embodiment comprises several large pro- 
grams with a number of steps that run on the desktop 
con^utcr, and a small file transfer program that runs as a 
^ slave on programmable handheld computers. The major 
steps of the main program are: 

1. Moping of fields from desktop data formats to hand- 
held data formats if required 
5j 2. Transfer of data from handheld to desktop 

3. Translation of data to desktop format 

4. Dynamic reconciliation of conflicts 

The mapping step establishes correspondences between 
fields of pairs of files. On import, the transfer step brings the 

60 handheld data mto the desktop computer. The translation 
st^ uses the rules provided by tiie mapping st^ to convert 
the handheld data in one format to desktop data in another 
format The dynamic reconciliation step informs the user of 
conflicts in the data and allows him to make decisions about 

65 whctha to accept the new data, ignore it, or change it A 
menu driver is provided to select which handheld applica- 
tions to translate to which desktop applications. 
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The prcfeired cmtxxliineDt also provides the capability to application communicatioD facility. An intcr-applicatioii 

export and translate data from the desktop computer to the communication facility is provided by some application 

handheld con^ter. In this case, the steps are: programs so that other programs may read and write data 

1. Mapping of Helds from desktop data formats to hand- files maintained by the application. In addition to the normal 
held data fcnnats if required 5 program start entry pointy the aj^cation program*s image 

2. Transfer of data from desktop to handheld has o&cr entry points that provide services like *Tell me (he 

3. Translation of data to handheld format names of all fields in yaar records/' "Give me the data 
Again, the above steps arc under the control of a menu format for the field whose name is BUSINESS PHONE", " 
driver. "Give me the next record key", "Give me the information of 

The following detailed description focuses on the 10 the CTrY field for the record whose key is 'John Jones*." 

m^ing, transfer, and translation between the handheld Wndows Dynamic Data Exchange (DDE) is an exan^dc of 

computer and the desktop computer as well as the dynamic this type of inter-application communication facility which 

recondUation of the data during translation. The mapping, is used by the preferred embodiment with desktop computer 

transfer, and translation of the data firom the desktop com- applications such as IBM Current and Polaris PackRat. 

puter and the handheld computer is essentiaUy identical ^hen neither of these two methods are available to the 

except that there is no reooncihatjon, because the desktop ^^^^ ^j^ng an undentanding of the 

datareplaa^s tfie handhdd data m the prefe^ed embodiment ^^^^^ structure, then in a third method, a description of the 

owmg to buat-m constraints m most handheld computers. , u ij» d ^ ^ *\ • 

FIQ. I shows a HANDHELD COMPUTER 101 with "l^^l'^^f^ handheld s byte-stream fomiat) is 
appHcations PHONE 103, SCHEDULE 105, TODO 107, *^"^f bard-coded m a way that makes the mformation 
DATA 109, and MEMO 111 transferring data to a desktop 20 available to the mappmg and translation f aciUties. In some 
computer using file transfer appUcation HHCOMM 113. ^® developer of the appUcation publishes the file 
HHCOMM 113 is responsible for accepting the data fi-om format For instance, for the HP95LX handheld computer 
the handheld computer and translating it to the COMMON SCHEDULE application, the byte stream representation of 
RECORD STRUCTURES, which are defined by the pre- the file's record structure is: 
fecred embodiment The COMMON RECO RD S mUC- 25 
TUREs are then passed to DESKTOP COMPUTER 115 by 
transfer application DTCOMM 117 which utilizes DTXLT 
119 inter-application communications or database manager 
facilities as appropriate to translate the data to formats 
accepted by desktop applications PERSONAL INFORMA- 30 
TION MANAGER 121, DATABASE MANAGER 123, 
SPREADSHEET PROGRAM 125, or WORD PROCESS- 
ING PROGRAM 127. The preferred embodiment provides hard-coded record 

Before communicating with the desktop application, the descriptors for the PHONE 103, SCHEDULE 105, TODO 

user may specify die mapping of handheld and desktop 35 107, DATA 109, and MEMO 111 applications provided by 

application data for the PHONE 103 and DATA 109 appli- each of the supported handheld computers. In some cases the 

cations by utilizing the mapping facilities of DTMAP 129. field names are obtained from the actual field names in the 

A default mapping is provided for the odier applications. handheld con^Miter's implementation and used as the field 

Hie user may optionally request from DTRECON 131 names for the target application. An example of this would 

lhat conflicts between the handheld and desktop data be 40 be the DATA application in the programmable Psion Series 

reconciled dynamically, thereby giving the user the option of 3 handheld coaq)uter. 

accepting, ignoring, or changing any conflicting d^ In a fourth metiiod contemplated by the inventor but not 

The mapping step of the program builds a set of rules tiiat iic^lemented in the current embodiment, a data dictionary of 

tiie translate step will use to translate data from one record the record structure can be coded into a text file, and the 

structure to another. The noting step must be run once for 45 m^ing step can read and intcri^et this text file much as it 

each pair of source-destination file formats where one of the reads and interprets a database's data dictionary, 

files is a keyed datat>ase, such as PHONE 103 or DATA 109. Once the mapping facility has acquired an understanding 

The ou^ut of a mapping step is a mapping database that can of the fields of each of the two record structures, the next 

be used for any number of translate steps in the fudirc. step is to establish the actual field m;^pings — ^for instance, 

There are two steps to the mapping process: (1) Acquiring 50 to establish a correspondence between a PHONE 103 field 

tile field names and data format of each field of each of the of file format 1 and a FAX NUMBER 307 field of file format 

two record structures; and (2) establishing a correspondence 2, and to determine the data conversion rule for mapping a 

between the fields of the source structure and the destination datum of field PHONE to a datum of field FAX NUMBER 

structure. Once a mapping between two record structures is 307, for instance "convert 3 2-byte integers to 10 ASCH 

estat^bed. it is maintained in a field mapping database for 55 characters.** This is accomplished by a user, who is pre- 

use by the translation steps. sented with a list of all the fields of each of the two record 

There are three methods by which field names and data structures, and then asked to select corresponding names, 

formats can be acquired, each method described in more It is sometimes preferable to not provide a mapping 

detail in following paragraphs. directiy fi*om the source application's file fonnat to tiie 

Some files, notably including files managed by database 60 destination application's file format, but to provide map- 
manager programs, have data dictionary records as headers pings fi^om the source fwrnat to a COMMON RECORD 
in tiie database file. These data dictionary records provide STRUCTURE 200, and a moping from the COMMON 
cxacdy the information required. For example, the Paradox RECORD STRUCTURE 200 to the destination format This 
Engine data access fadUty provides all field names for a case is most typical when one or both of the file formats are 
Paradox database upon request in the pref ared embodiment 65 in the third brute-force category. The COMMON RECORD 

In a second method, the appUcation program provides this STRUCTURE 200 is typically chosen from one of the 

infonnation to the mapping fadlity through an Inter- application programs* record structures. For instance, in the 
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case of handheld cojoputer PHONE 103 files, the program MAPPINGS database are bi-directional (Le., the mappings 

translates all PHONE 103 databases into the format used by are applicable both for handheld computer to desktop 

the Sharp Wizard® handheld computer. The COMMON computer, and desktop con^utcr to handheld computer), the 

RECORD STRUCTURES 300 are defined by the preferred appearance of multiple records in the MAPPING database 

embodiment for applications PHONE 103, SCHEDULE 3 with the '^multiple field flag" can cause multiple fields from 

105, TODO 107, DATA 109, and MEMO 111. These formats a source database to be combined in a single field in a target 

generally are determhied by the hardware characteristics of database. For instance, the example of FIG. 5 shows a case 

the handheld computer. They are hard-coded into die pre- where one field in the handheld application (ADDRESS) can 

f erred emibodimeat for each handheld computer. PHONE be mapped to eight fields in the desktop application by 

103 and DATA 109 arc similar and provide for a single- lo specifying mapping for ADDRESS_XINE1 through 

keyed indexed database with multiple subfields allowed in ADDkESS_JJNE8. 

non-indexed fields. Examples of the COMMON RECORD FIG. 9 shows the fields for the MAPPING database. **HH 

STRUCTURES 300 are shown in FIG. 2 for ^plications Type" specifies the handheld make^modcl, such as the Sharp 

PHONE 103, SCHEDULE 105,TODO 107, DATA 109, and Wizard, HP95LX Palmtop Conq)Uter, the Casio B.O.S.S., 

MEMO 111. 15 and the Psion Series 3. "HH Application" specifies the 

FIG. 3 shows an example of translation of data between handheld application name, such as PHONE, SCHEDULE, 

the COMMON RECORD STRUCTURE 200, containing or MEMO. "DT Application" specifies the desktop applica- 

DATA RECORDl 361, DATA REC0RD2 363,. , . DATA tion name, such as PackRat. or dBASE. "DT File Name" 

RECORDn 367 to various desktop applications such as a specifies the name of the desktop database file, such as 

PERSONAL INFORMAnON MANAGER 121 containing 20 C:\SK2\ADDRESS.DB for the Sidekick 2.0 PHONE/ 

PERSON 371 data h&lds (NAME 301, BUSINESS PHONE ADDRESS appUcation. "HH File Name" specifies the name 

303, HOME PHONE 305, FAX NUMBER 307, TITLE 3D9, of handheld database file such as CiV-DAT JLJPBK for the 

COMPANY 311, STREET 313, CnT, STATE 315, ZIP 317, name of the file to be used by the PHONE application on the 

and NOTES 315>), APPOINTMENT 373 data fields PATE HP95LX. **Record Number" specifies the unique record id 

321, STAKTTIMB 323, ENDTIME 325, ALARM 327, and 25 of the record in the MAPPING database which is required by 

DESCRIPTION 329), and TODO 375 data fields the preferred embodiment for recOTd uniqueness from a 

(DESCRIPTION 331. PRIORITY 333, DUE DATE 335, processing standpoint **HH Field Name** specifies the name 

and DETAIL 337). of the handheld field and subfield number for each moping 

FIG. 3 also shows the DTMAP 129 function which record, such as ADDRESS_JJNE3. 'OT Field Name" 

provides field moping for a DATABASE MANAGER 123. 30 specifies the field name within *T)T File Name", such as 

The usCT of the prefcucd embodiment is allowed to specify BUSINESS PHONE. **Multiple Field flag" is an indicator 

the destination field that corresponds to each field in the that "HH Field Name" is a member of a group of multiple 

handheld application database. As the translation takes fields to be mapped to/from a single physical field. ''Number 

place, the fields are mapped according to the user specifi- of HH Fields" specifies the number of real handheld fields 

cation into the desktop application database. 35 in the handheld computer, which is information needed by 

FIG. 4 shows an example of field mapping between an the prefcucd embodiment (manually provided in the pre- 

application's data 109 (FIELDl 401, FIELD2 403, FIELD3 ferred embodiment). 'Tield T^pe" spedfies the field type of 

405, FIELD4 407, FIELD5 409) of a HANDHELD COM- "DT Field Name", such as A025 for ASCH, 25 bytes. 

PUTER 101, and a database manager application's data **Number of Keys", specifies the number of fields in the 

(CUSTOMER NAME 413, CUSTOMER NUMBER 415, 40 desktop database manager's database. 

ORDER DATE 417, QUANTITY 419, I TEM 421, and The MAPPING database is created using an off-the-shelf 

PRICE 423) of a DESKTOP COMPUTER 115. database manager; in the prefeiied embodiment it is Paradox 

FIG. 5 shows an exan^le of the preferred embodiment's or C-Trcc At MAPPING database aeation time, the above 

screen display which allows the user to specify field map- gelds are defined. Each handheld plication is introduced 

ping. In this example, the translation is between a handheld 45 to the MAPPING database by manually entering the "HH 

computer's TEL database and &e PARADOX database. In T^pc", **HH Application", DT Application", **Rccord 

FIG. Soy the user has selected a handheld field from the TEL Number**, "HH Field Name**, "Multiple Field flag", **Num- 

column, sudi as ADDRESS_UNE2, and a desktop field bcr of HH Fields", and '"Number of Fields** fields **DT File 

from the PARADOX column, in this case (JTY. The selec- Name" and HH File Name" are created dynamically during 

tion is made by clicking a mouse (or trackball, or other 50 m^^ing by the preferred embodiment. For some desktop 

pointer device) on the two respective field names. In FIG. applications, such as Polaris PackRat, the "DT Field Name'* 

Sb, the mapping between these two fields is completed, and **Field TVpe" are manually entered into the MAPPING 

denoted by the field name from die desktop database dis- database. For some odier desktop ^plications such as 

played in Uie middle mapping column next to the field name Paradox, the Paradox Engine can be used to query a Paradox 

from the handheld database. The mapping is stored in a 55 database to provide the "DT Field Name'* and **Ficld Type**. 

MAPPING database, which is referenced during the trans- Pseudocode for the specification of field mapping of data 

lation operation. between the handheld computers and the desktop computer 

The MAPPING database will be used during the transla- ig shown in TABLE 1. The code implementing this is on 

tion process to determine where data from each field of the pages 60^5 of the microfiche appendix, 
source application record is to be stored in the target $o 

application record. Each record of the MAPPING database TABLE 1 

describes all or part of the mapping of a single field of a — — 

handheld application's data file. In the case where a single Pseudocode fbr Specification of Held Mappaig of Data 

field in the source database is to be mapped to multiple fields between Handheld and Desktop Applications 

in the target database, multiple records will appear in the 65 loi open mappino database 

MAPPING database for that target field, with the '^multiple 102 Display handlKld field names 
field flag" set to TRUR Because die mappings in die 
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TABLE l-continued 

Pseudocode for Specification of FteU Mapping of Data 
between Haodbeld and Desktop Applications 



103 IF in^>ping pzevicusly spocifiod 

104 Di^by TpscyjOMB desktop field mapiriiigs 

105 DO UNTIL user presses OK button 

106 IF user specifies a luDdbek} field to re-map 

107 Display deddcp fiekb which are eligible for 
mapping 

108 Ask user for desktop field to map 

109 Update tfesklop fiekl table for specified 

haodbeU fiekl 

UO Display xiew desktop field mapping 

111 ENDF 

112 IF user specifics Cancel 

113 Exit 

114 END DO UNTIL user picsses OK button 
lis Write new MAFFINO database 



The prefcucd embodiment allows the use of onc-to-many 
field mappings and many-to-one field mappings. One-to- 
roany means that a single text field in the handheld appli- 
cation's data file can contain several pieces of data, delim- 
ited by special characters, which will be translated to 
multiple fields in the desktop applications data file. Many- 
to-one means that the reverse translation will take place. 

Hie onc-to-many and many-to-one relationships are 
accon^lished in the preferred embodiment by specifying 
multiple mapping records in the MAPPING database for a 
single field in either the handheld conqxiter or the desktop 
application. These records are marked specially as muldple- 
field-mappings for the translation process. Multiple-string 
fields are noted in the hard-coded description of fiic record 
structure (method 3). Future implementations will allow the 
user to spediy that a field has multiple subfields on a 
point-and-click menu. 

In the preferred embodiment, the user is presented with a 
screen as shown in FIG. 5 which displays the selections 
available for mqsping. If the user wishes to establish map- 
pings from the handheld ADDRESS 205-209 field in the 
PHONE 103 application to a desktop Paradox database with 
fields sudi as TTTLE 309, COMPANY 3U, STREET 313, 
CrTY, STATE 315, and ZIP 317, he is presented with 
subfields ADDRESS_J-inel 205, ADDRESS_aine2 207, . 
. ADDRESSJLineN 209 fields fcH" mapping. He then 
selects the subfield of ADDRESS Jinel 205 by clicking on 
the ADDRESS^Iiacl 205 and selects the desktop target 
field TITLE 309. He then selects the subfield of 
ADDRESS_Xine2 207 by cHddng on the ADDRESS^ 
Iine2 207 and selects the desktop target field COMPANY 
311. The process is rqpeated f(x each handheld subfield and 
desktop target field. 

The above process results in six records in &e MAPPING 
database; the first maps ADDRESS_Unel 205 to TITLE 
309, ADDRESS_Line2 207 to COMPANY 311, 
ADDRESS Jjne3 to STREET 313, ADDRESS_Xine4 to 
CTTY 315, ADDRESS_Line5 to STATE 315, and 
ADDRESS JJne6 to ZIP 317. Special coding in the pre- 
ferred embodiment handles the CTTY, STATE pairing. These 
records will be used by the translation process to map the six 
subfields in the ADDRESS field of each record from die 
handheld computer to the six desktop fields in each target 
record in the desktop computer. 

The first step in the use of the mapping and translation 
facilities descril)ed is to copy data from a desktop con^)uter 
to a handheld, or vice-versa. 

FIG. 2 shows a handheld computer application 
HHCOMM 113 transferring PHONE 103 data fields 
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(NAME 201, NUMBER 203. ADDRESS 205, etc.), 
SCHEDULE 105 data fields (DATE 211, STAKTTIME 213, 
END TIME 215, ALARM 217, and DESCRIPTION 219), 
TODO 107 data fields (PRIORITY 221, DUE DATE 223, 

5 and DESCRIPTION 225). DATA 109 data fields (FIELDl 
227, FIELD2 229, .. . FIELDn 231), and MEMO 111 data 
fields (DESCRIPTION 233 and TEXT 235) to desktop 
computer application DTCOMM 117, which reads and 
translates the handheld computer data to the COMMON 
RECORD STRUCTURE 200 containing DATA RECORDl 
237, DATA REC0RD2 239, . DATA RECORDn 243. 

Once the mapping has been specified and the data 
transferred, the translation may take place. The translation 
process for PHONE 103 and DATA 109 handheld data to 
database manager databases is controlled by the MAPPING 
database. Each record represents a field or subfield of the 
handheld computer's data. The mapping is peribrmed to 
fields in the desktop application's database based on the field 
names of the desktop's application. 
The MAPPING database for the data in FIG. 4 would 

20 contain records as shown in FIG, 10, In this case, FDSLDl 
data firom the handheld would be mapped to the CUST- 
NAME field of the desktop application, F1ELD2 data from 
the handheld would be mapped to CUSTNO, FIELD3L1 
data would be mapped to ITEM, FIELD3L2 data would be 

25 mapped to QTY, FIELD3L3 data would be m^ped to 
PRICE, and FIELD3L4 data would be m^ped to ORD- 
DATE. In this mapping, FIELD3 of the handheld computer 
is a multiple-field mapping. FIELD3 has four subfields 
which are mapped to four fields in the desktop computer 

30 database. 

Pseudocode for typical application-specific translation of 
keyed PHONE 103 or DATA 109 files between handheld 
applications and desktop applications is shown in TABLE 2. 
The code implementing this in the preferred embodiment is 
35 on pages 65-66, 102-106, 179^187, 203-206, and 237-246 
of the microfiche £q>pendix. 

TABLE 2 

40 Pseudocode for Translating PHONE 103 or DAIA 109 fiks 

101 Read MAFPINQ daUbase 

102 Build mapping stnictme for translatiaa 

103 DO UNUL hst baadbeld wpvt record has been ttad 

104 Read handheld input record 

105 DO FOR each handheld iapat field 

106 Perform translatioos such as canvczsion 
bom handheld computer binary fbmxat to 12- 
hour ASCn AM/FM tamat (specific to each 
handheld computer) 

107 Build output field or multiple fields when 
there are multiple mappii^ recozds per field 

50 (onc-io-many) 

108 END DO FOR each ii^ut field 

109 Write output record 

110 END DO UNTIL aU input data records have been read 



55 In Step 102 of TABLE 2, the mapping structure is an 
internal data structure presenting the ihforniation needed fen: 
translation from the MAPPING database, containing the 
name, format, mapping, and mult^le-field-mapping charac- 
teristics of each iield. The process of building these data 

60 structures is accon^lished by reading the MAPPING data- 
base and storing its data in the structure for reference during 
the translation. The structure is an intemal image of the 
MAPPING database built to facilitate processing in the 
preferred embodiment 

65 Step 105 through 108 iterates through records in the 
mapping structure. Step 105 is performed for each field of 
the handheld computer's data. 
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Each handheld computer has its own format for Its 
application data files. The data translations of step 106 are 
hard-coded into the translation facility of the preferred 
embodiment for each pair of source and destination data 
formats » as discussed earlier for the HP95LX handheld 
computer. An example is the conversion of the three single- 
byte integer fields in the HP95LX date to an ASCII- 
formatted date of mm/dd/yyyy. The year byte in the 
HP95LX format is number of years since 190Ot so 1900 
must be added to the single-byte integer (which has a 
maTimum value of 255). In these data format conversions, 
the source bits differ from the destination bits, bat the 
information — the meaning of those bits in the context of the 
record structure rules — ^is the same. 

Step 107 iterates through records in the mapping stmcture 
for fields in the handheld computer which have multipi&- 
field-mapping characteristics. In this case, multiple mapping 
records will exist in the mapping structure (one for each 
subfield). If a field in the source fiie has been mapped to 
multiple fields in the destination, the splitting occurs by 
recognizing tabs as subfield separators in the first file. 
Conversely, if several fields in the source m^ to a single 
field in the destination, the strings of the source fields axe 
catenated together into the destination field with tab sepa- 
rators. 

The danger presented by the above-described transfer and 
translation facilities is the classic consistency problem. Once 
data has been copied to two separate computers, different — 
and inevitably conflicting — updates may be ^plied to the 
two separate copies of the data, The user will often update 
the schedule be carries in his handheld computer, and the 
user's seaetary may make changes to the desktop comput- 
er's data while the user is away. 

Dynamic recondHation allows the user of the handheld 
con^uter to make changes to the handheld computer while 
away from the desktop computer and discover the effect of 
these changes when returning to the desktop computer. The 
dynamic reconciliation runs on the desktop computer during 
the translation process from the handheld computer to the 
desktop computer and usually includes mapping of files of 40 
different formats. 

FIG. 3 also shows the DTRECON 131 (Desktop 
Reconciliation) function which provides optional dynamic 
reconciliation of application-specifi.c conflicts between 
incoming (handheld) data and existing (desktop) data, with 45 
capabilities to accq)t, ignore, or change incoming data. If a 
record from the handheld computer has a key which matches 
a record in the desktop computer, each handheld field of the 
record is compared to each desktop field. If they are 
different, the user is queried for resolution. 

FIG. 11 shows an example of data for a database man- 
ager's database in FIG. 4. In this case, when a translation 
takes place from the handheld computer database of user 
DATA 109 with fields FIELDl 401, FIELD2 403, FIELD3 
405, FIELD4 407, and FIELDS 409 and a desktop computa 
^plication's data CUSTOMER NAME 413, CUSTOMER 
NUMBER 415, ORDER DATE 417, QUANTirY 419, 
ITEM 421, and PRICE 423 conflicts would result during the 
translation of handheld data records 2 and 5 because their 
FIELD3L2/(3TY and FIELD3L3/PRICE fields are different 
for the same bey (which is FIELDl/CUSTNAME), The user 
would be proii^)ted to choose whether to accq)t the data 
from the handheld computer. 

The preferred embodiment allows the user to be option- 
ally notified during translation if any of the existing data in 
the desktop application are different from the data in tiie 
handheld application. FIG. 7 shows an exaii^le of the 



preferred embodiment's screen display which allows the 
user to decide what to do about conflicts. In this case, the key 
field is Name. If a record exists in the desktop application 
with the same Name, the data in eadi field in the desktop is 
compared with the data from the handheld. If the data in any 
given field is different, the user may accept the update to the 
field, ignore it <x edit part or all of the incoming data in the 
record and write it to the desktop application* s file. Note that 
the final result may be to update some fields of the desktop 
record and not others. 

An example of an implication-specific technique is docu- 
mented in TABLE 3 for the import of handheld computer 
DATA 109 to a desktop computer DATABASE MANAGER 
123 which contains an earlier version of the data in the 
handheld con^)uter. The preferred embodiment's code for 
this is on pages 110-111 and 246-248 of the microfiche 
appendix. 

TABLE 3 

Pseudocode for Recaociliation of Data tar DAIA 109 
Applicadcm (occurs for each record dnnng TranstatioQ, Step 
105-108 in TABLE 2) 



35 



50 



55 



60 



65 



101 



102 
103 



104 
105 



106 
107 
108 
109 
110 
111 
112 
113 
114 
115 



Query desktop application for enstcnce of 

handheld record key in desktop database 

IP there is a desktop record with the same key 

DO UNTIL all fields in the handheld record are 
checked (based on mapping) 

BEGIN 

IF the handheld and desktop fields are ifn^taT 
Ask user to pick the handheld field, the 
desktop field, or wishes to ch2z^ die 
faanditf Id data and use die changed data 
IF user wishes to change the h*^ p *^h pM data 

Update handheld field with changes 
ELSE IP user selects handheld data 

Update {ksktop field with handheld data 
END IF 
END IF 
END DO 



create a desktop record from the handheld data 
ENDIF 



Step 101 utilizes either a database manager query or an 
inter-application commumcation facility to determine if 
there is a record in the target application with the same key. 

Steps 102 and 103 may involve translating the informa- 
tion of both records into a common record structure dis- 
similar to the record structures of both files. This translation 
may involve data farmat conversion of the fields, but the 
information of the fields — the meaning of the fields as 
interpreted under the record structure rules — is preserved. In 
this case, steps 107 and 109 involve another translation of 
the information into the correct record structure for writing 
to the handheld or desktop. 

The preferred' embodiment also performs translation from 
the desktop computer to the handheld coiiq)uter utilizing 
techniques similar to TABLE 2. 

TABLE 2 describes the translation process for a keyed 
database. Some applications such as the SCHEDULE 105 
application do not have unique keys and have special 
characteristics. In this case, a different translation process is 
required. For example, in the preferred embodiment a single 
input record can generate multiple ou^ut records, such as 
repeating appointments. A repeating appointment typically 
is daily, weekly, monthly, etc. until a specified date, and with 
a description, for instance, *3rant^ Office Meeting" every 
Monday at 10:30 for the next two years. 

Pseudocode for typical translation of data between the 
handheld application and the desktop application for the 
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SCHEDULE 105 qjplicatioa is shown in TABLE 4. The 
preferred embodiment's code implementing this is on pages 
97-102, 174-179, and 232-237 of the microfiche appendix. 

TABLE 4 

Pseudocode for TnnslatioD of SCHEDULE 105 files 

101 Opca handheld fik obtaizked fiom handheld appticatkn 

102 Ktfahlidi connnunicadoa with the desktop application 

utili^ng inler-ipplication oommucication or a 
database manager, as appiopiiate 

103 DO WnL last handheld record has been processed 

104 IP the handheld recoid is a repeating appointment 

105 DO UNTIL all repeating appointments are cieated 

106 Create deitop ^ipointment reoord 

107 END DO 

108 ENDIF 

109 Translate appointincot data 

110 IF the user requested notificatioQ of conflicts 
lU Check SCHEDXJl£ MAP TABLE 601 for conflict 

112 IP conflict exists 

113 Ask the user to accept/igmre/chaiige record 

114 ENDIF 

115 ENDIF 

116 END DO 



10 



15 



25 



30 



35 



45 



Some applications such as &e SCHEDULE 105 plica- 
tion have (possibly non-unique) range kcys^ rather than the 
unique point keys assumed in the reconciliation process of 
TABLE 3. In this case, the preferred implementation utilizes 
a special technique which performs reconciliation based 
upon the date and time of appointments. This type of 
reconciliation is not field-by-field as in a keyed database; it 
is based on the entire information of the appointment record 
being evaluated and compared to the existing overall sched- 
ule on the desktop. 

The technique requires a SCHEDULE MAP TABLE 601 
which contains all existing 2f>pointment$ in the SCHEDULE 
1«5 data. An example of data in the SCHEDULE MAP 
TABLE 601 is shown in FIG. 6 (DATE 2U, START TIME 
213, END TIME 215, ALARM 217, DESCRDPTION 219). 
This table is searched for eadi incoming appointment to 
determine if there is a confiict in scheduling between the 
incoming appointment and all existing appointments in the ^ 
desktop schedule. 

For exan^lc, if an £9>pointment from the handheld com- 
puter had a DATE 211 of Dec. 15, 1991, a STAKTTIME 213 
of 10:00 AM, and an END TIME 215 of 11:30 AM, the 
SCHEDULE MAP TABLE 601 would indicate to the pre- 
ferred embodiment that there is a confiict with the second 
:9)p<antment in the SCHEDULE MAP TABLE 601 which 
shows an appointment on Dec. 15, 1991 from 11:00 AM to 
1:00 PM. Ail times are convoted to a 24-hour format to ease 
comparison. If an appointment shows an identical DATE 
211, START TIME 213, END TIME 215, and DESCRIP- 
TEON 219, diere is no conflict and the incoming appoint- 
ment is ignored. 

The preferred embodiment of the SCHEDULE RECON- 
OLIAnON fadUty creates a SCHEDULE MAP TABUE 
601 by requesting all appointments for today and the future 
from the desktop schedule plication. For exan^le, the 
preferred embodiment utilizes Windows 3.0* s Dynamic 
Data Exchange facility to request all schedule items from the 
desktop personal informatioD manager Polaris PackRaL Tills 
results in a complete evaluation of all existing appointments 
in the desktop schedule. The resultant data are then used to 
build the SCHEDULE MAP TABLE 601 in the memory of 
the desktop computer. The SCHEDULE MAP TABLE 601, 
ah example of which is shown in FIG. 6, is used for 
comparison during the translation of schedule data from the 
handheld conqxiter. 



Another method of querying schedule information from a 
handheld con^niter involves running the schedule aj^lica- 
tion as a slave of die schedule reconciliation program. The 
reconciliation program issues requests to the schedule 
application, and the schedule application presents the 
appointments one by one to the reconciliation progranL 

The SCHEDULE RECONCDLIAFION facility then 
requests each appointment from the handheld schedule 
application by whatever access method is provided by the 
handheld application, and compares each appointment 
obtained from the handheld to the SCHEDULE MAP 
TABLE. If the handheld appointment is a repeating 
appointment, then it is expanded into multiple records, as far 
into the future as specified by the repeating ^pointment 
record. This can result in multiple records being produced in 
the destination file as the image of a single repeating 
appointment record in the source file. 

Schedule conflicts (or, more generally, conflicts between 
two records with range keys) can be of two kinds: either an 
20 inexact overlap conflict, or a difference conflict An inexact 
overlap conflict is when two range keys overlap, but are not 
cxacdy the same: for instance, an appointment in the hand- 
held^s schedule database overlaps an s^pointment in the 
desktop*s schedule database, but one begins or ends earlier 
than the other. A difference conflict is detected when the two 
range keys are exactly the same — the appointments begin 
and end at the same time — but the text describing the 
appointment differs in the two databases. A third kind of 
discrepancy arises when a range key in one database has no 
overlapping range key in the other database — for instance, 
an ^pointment was added in one schedule database but not 
the odien 

FIG. 8 shows an example of the preferred embodiment's 
screen display which allows the user to decide what to do 
about conflicts. In this case, the SCHEDULE MAP TABLE 
601 has been searched to determine if there is an appoint- 
ment during any of the time between 9:00 AM and 10:00 
AM. There was an ^pointment named "Announcement" 
from 9:30 AM until 10:30 AM. The user may accept the new 
appointment, ignore it, or change the time or date of the 
incoming ^pointment and accept If the data is changed, it 
will be re-diecfced for conflicts against the SCHEDULE 
MAP TABLE 60L 

Pseudocode for typical application-specific reconciliation 
of data between the handheld conq)Uters and the desktop 
computer for the SCHEDULE 105 application is shown in 
TABLE 5. The preferred embodiment's implementation of 
this is on pages 101, 177-178, 235, and 284-288 of the 
microfiche appendix. 
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TABLES 



Pseudocode fbr Reconciliation of Data for SCHEDULE 105 
Applicatian (Steps 106-117 of lABLE 3 occur for each rccofd 
during 'nansIatioQ, Step 111-115 in TABLE 4) 
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101 Establish communication with the desktop application 

102 DO UNIIL last desktop Schedule has been queried 

103 Read desktop schedule item 

104 Add (ksktop schedule Item to SCHEDULE MAP TABLE 601 

105 END DO 

... fbr each iteration of TABLE 4, Step 111-115 

106 Look tq» handhftH reocrd's date and time range in 

SCHEDULE MAP X^LE 601 

107 IF an item exists with overlapping date and time 

108 IP the descnptxm is diffexent 

109 Ask the user to select Accept, l^goare, or Change 

110 JPtbc user changes the handheld date or time 

111 Restart DO UNTIL 
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TABLE S-continued 
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Pseudocode for Reconciliation of Data for SCHEDULE 105 
Application (Steps 106-117 of TABLE 5 occur for each record 
during 'Kamlation, Step 111-115 in TABLE 4} 

U2 IF the user selects Accept 

U3 Add the item to the deslctop 

U4 END IF 

115 END IF 

U6 ENDF 

117 END IF 
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TABLE 5 expands on the reconciliation section of 
TABLE 4, which describes the translation process for the 
SCHBDULB 105 ^plication. First, the existing appoint- 
ments in the desktop computer are requested from the 
desktop SCHEDULE 105 application. The SCHEDULE 
MAP TABLE 601 is built based on those appointments. This 
is done before any translation takes place. Then, each 
appointment from the handheld conq)uter is evaluated based 
on DATE 211, STAKT TIME 213, END TIME 215, and 
DESCRIPnON 219 to determine if any overlapping time 
exists. If there is any overlap and the DATE 211, START 
TIME 213, END TIME 215, and DESCRIFnON 219s are 
not exactly equal, the user is queried for resolution. 

The resultant appointments are stored on the desktop via 
either a database manager or inter-applicadon communica- 
tion facility. 

The discussion of the prefetied embodiment concentrated 
on the mapping, transf^ and reconciliation of data from a 
handheld computer to a desktop. The same techniques can 
be applied to map, transfer and reconcile data from a desktop 
to a handheld, between two desktop computers, or between 
handheld computers, or between applic^ons on the same 
computer. 

Because each model of handheld conqjuter is slightly 
different in tiie way it communicates with a desktop, the 
preferred embodiment includes a small communciations 
component, 113 of FIG. 1, that must be customized to each 
handheld computer. Directions for using the preferred 
embodiment with each handheld computex difos; two edi- 
tions of the owner's manual, for the Sharp ^^ard® and the 
Hewlett-Packard HP95-LX, are attached as appendices one 
and two. 

Many other embodiments of the invention are within the 
following claims. 
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What is claimed is: 

1. A method for a user of a computer to interactively 
reconcile records of a first and a second database, wherein 
the record structures of the first and second database are 
different, the method coxnprising: 

translating records of at least the first database to assist in 
comparing records of the first and second databases; 

choosing corresponding records, one from the first data- 
base and one from the second database, based on a 
con4)arison of the content of at least one selected fidd 
from each record; 

comparing the content of at least one additional field from 
each record to detect differences in content between the 
records; 

using the detected differences in content to decide 
whether a conflict exists t)etween records; 

displaying information representative of the detected dif- 
ferences in content; and 

allowing the user to decide between alternatives for 
resolving the conflict 

2. The method of claim 1 wherein the altonatives for 
resolving the conflict comprise replacing the content of the 
one additional field in one of the databases with the content 
of the one additional field in the other of the databases. 

3. The method of claim 1 wherein the altonatives for 
resolving the conflict comprise allowing the user to edit the 
content of the one additional field in at least one of the 
databases. 

4. The method of claim 1 wherein records of both the first 
and second database are translated to a common reccn'd 
structure prior to choosing and comparing actions. 

5. The method of daim 1 wherein the at least one selected 
field from eadi record is a key field. 

6. The method of daim 1, 2, 3, 4, or 5 wherdn the first and 
second databases are calendar databases, and the records 
coitpise records representing appointments or events. 

7. The method of daim 6 wh^ein the at least one selected 
field used for choosing records is other than a date or time 
field. 

8. The method of claim 1 wherein the translation com- 
prises mapping of fields of the first database to fields of the 
second database. 

9. The method of daim 8 wherein the moping is specified 
by the user. 



05/26/2004, EAST Version: 1,4.1 



UNITED STATES PATENT AND TRADEMARK OFFICE 

CERTIFICATE OF CORRECTION 

PATENT NO. : 5, 666, 553 

DATED : September 9, 1997 

INVENTOR(S) : Keith Crozier 

It is certified that error appears in the above-identified patent and that said Letters Patent is 
hereby corrected as shown below: 

Cover page 2, [56] References Cited, U.S. PATENT DOCUMENTS, 
at "5,519,606% "Frid-Wielsen et al . " should be 
- -Frid-Nielsen et al.--. 

Cover page 2, [56] References Cited, OTHER PUBLICATIONS, at 
"Logical Connectivity...", "Application" should be 
--Applications-- . 



Col, 1, line 11, after "form", delete "of a f iche" . 

Col, 1, line 11, "330 pages" should be --328 pages--. 

Col. 8, line 39, after "Keys'", delete 

Col. 8, line 48, after third occurrence of "fields", insert 



Attest: 



Signed and Sealed this 
Eleventh Day of August 1998 

/^L^ tc/fh/U 



BRUCE LEHMAN 

Attesting Officer Commissioner of Paten ts and Trademarks 



05/26/2004, EAST Version: 1.4.1 



UNITED STATES PATENT AND TRADEMARK OFFICE 

CERTIFICATE OF CORRECTION 



PATENT NO. : 5, 6 66,553 

DATED : September 9, 1997 

INVENTOR(S) : Keith Crozier 

It Is certrfied that error appears in the above-identified patent and that said Letters Patent is 
hereby corrected as shown below: 

Column 2, line 51; "U.S. Pat. No. 4,966,809" should be 
--U.S. Pat. No. 4,956,809--. 



Attest: 



Signed and Sealed this 
Third Day of November, 1998 



BRUCE LEHMAN 

Attesting Officer Commissioner of Patrnts and Trademarks 



05/26/2004, EAST Version: 1.4.1 



